STARSHIP OPERATIONS AND CRAFTING IN STAR TREK ONLINE

 

2007/04/10

 

INTRODUCTION

I'd like to begin by clearly stating my thesis: I think Star Trek Online (ST:O) needs functionally detailed player starships for players to live in and use for exploration of the game universe.

This post is intended to try to make the case for this suggestion. I understand that it's not the current direction for ST:O's design, but I believe it should be -- I think it's necessary if ST:O is to successfully exploit the Star Trek license. I also understand that this isn't a new proposal, but I think (I hope!) that I'm bringing something new to the discussion by offering some very specific ideas to beat up on.

Accordingly, what follows is a design vision of how groups of players can work together aboard starships in a way that communicates the spirit of Star Trek while also being fun as MMORPG gameplay.

I know this is not the flavor of the month right now. As of April 2007, Perpetual's position on the subject of player ship interiors with functional control stations could best be summarized as "ST:O will not be a starship simulator."

With respect, I believe that position needs to be challenged. Why is tactical effectiveness for the combat-oriented gamers controlling the gameplay design for all ST:O players? Why not "simulate" some of the cooler aspects of operating Star Trek starships? Using the advanced technology aboard a starship to solve problems has always been one of the things that made Star Trek fun. Lose that, and you instantly lose a significant portion of Star Trek's appeal.

Of course an online game will be different from a TV show or movie. Some things will need to be cut; that's understood. And it's also understood that there will be some gamers who only want to experience ST:O as a tactical combat game. Supporting them is fine, but what about everybody else? What about the people for whom the spirit of Star Trek is its humanism and intelligence in creative problem-solving? Shouldn't starships in ST:O be fun for them, too?

The problem with designing ST:O's starships as just mobile spawn points in a 3rd-person tactical fighting game is that this fails to make full use of the Star Trek license. As the example of Star Wars Galaxies shows all too painfully, if a game makes too many compromises to conventional MMORPG play, rather than insisting on features that capture the spirit of the license, the many people who were drawn to the license won't be attracted enough to the game to subscribe to it (and stay subscribed). That might work for a combat-only Warcraft, but who here truly believes that Star Trek, with its emphasis on ethical exploration, is that kind of license?

So of all the things to cut, such a critical part of the Star Trek experience as starship operation should not be on the hit list. Not only does that eliminate a core Star Trek experience, it fails to take advantage of a rare opportunity to offer innovative and enjoyable group gameplay beyond the conventional tactical combat of every other MMORPG. Not letting players work together to operate the systems of their ships is likely to mean fewer subscribers to the game because a crucial aspect of Star Trek is missing. Nobody will win when that happens.

I don't just mean "Star Trek Online needs to do ship interiors," either. If ship interiors are rendered prettily, well, that's nice, but enabling players to wander around inside a ship and stare at the walls is not my goal in this proposal. What counts is functionality. Players need to be able to interact with the individual systems of their ships: modifying shield harmonics, transporting objects with strange bio-signatures, reprogramming the sensor array to pick up a garbled and faint distress signal -- those are the kinds of things that matter in a Star Trek RPG! I'd be a lot happier if access to these systems was through a 1st-person LCARS interface, but the main thing is that ST:O lets players do the technology-manipulating things that Star Trek characters are supposed to be able to do.

Actually, I want to commend Perpetual for proposing the "hub" concept. If anything, I don't think it goes far enough. I think the majority of player ships need to be operable as multi-person vehicles containing complex systems that multiple players can access simultaneously; that's where most of the socialization in ST:O should be. But implementing ships and stations as complex systems that players will be able to interact with is an attempt at a compromise, and I respect that.

That said, I'd like Perpetual to see how far this idea can be pushed. I believe they'll find that many of the people who come to ST:O for the Star Trek experience will expect starship operations to be a core gameplay element, and will be disappointed when they discover that ST:O's design focus for starships is on "exciting" destruction. ST:O needs the exploration-focused group vehicles that are a fundamental part of Star Trek, and it needs them to be standard-issue by design.

I realize that I'm swimming upstream on this one, and I'm definitely not trying to annoy anyone, so I won't be offended if the general feeling is that I've wasted my time on all this. Even if the core vision described here has no chance of being applied in ST:O, perhaps some of the associated ideas may prove useful in designing gameplay for "hub" ships. And if nothing else, I had fun developing these ideas -- it's been an interesting exercise in systems design.

So to anyone who's suffered through this introduction and who survives the following exposition -- thank you! I hope you'll find something you like here.


"CRAFTING" AS AN ICONIC STAR TREK ACTIVITY

In the universe of Star Trek, characters always face challenges.

Sometimes these challenges are physical, requiring the character to face a fear of injury or death. Sometimes the challenges are social, such as negotiating a peace treaty, establishing a trade agreement, or initiating a first contact. And sometimes the challenges are ethical, as when a character's fidelity to the Prime Directive is tested. If Star Trek Online's gameplay fairly represents the license, we can expect to see plenty of all these types of situations.

But the Trek mythos is nearly unique in popular fiction in how often characters are required to surmount intellectual challenges -- in particular, technological challenges. In the world of Trek, there are innumerable occasions when neither brute force nor diplomatic savoir-faire will work -- the only way to solve a difficult problem is through the creative use of advanced technology.

I think the path to providing fun intellectual challenges to ST:O players can be summed up in one simple word: "crafting." Not crafting in the sense of manufacturing, of making stuff to sell in an in-game economy, but crafting in its larger sense of creating interesting new things. The art and science of crafting is the exploration of technology... and that, in the service of an ethic of curiosity about and respect for sentient beings, is exactly what Star Trek has always been about.

In short, Star Trek Online needs crafting. And the best way to get it is by designing all of the hardware and software objects in the game -- especially including starships and their systems -- to be decomposable into components that can then be recombined in novel ways.

Although this concept should apply to every object, from handheld tools to warp cores, by far the most important vehicle for it is the starship. Not only are starships crammed with groovy technogadgets and clever software programs, they are full of that most glorious of resources: systems. For all their advanced hardware and software, without the systems that organize and control those things a starship would just be a box full of parts. When they're pieces of an intelligently-designed system, however, and those systems are operated by people who share a common goal, the whole supersystem becomes more than just the sum of its parts -- it becomes an incredibly powerful tool for exploration.

Working with the many systems that constitute this exploratory tool is what characters in the Trek universe do. They travel to distant places, seeking out new life and new civilizations, and they use the powerful systems of their starships to solve the problems that explorers inevitably encounter.

Which means that to see how crafting can work in ST:O, we need to look at how Trek characters use a starship's systems. Anyone who's tried their hand at designing a starship knows that there are many pieces, but how do those pieces fit together as an organized collection of systems? And how do Trek characters interact with those systems to achieve specific goals?

Our first step in answering these questions will be to enumerate the best-known systems of Star Trek starships. Then we'll examine those systems according to their organizational structure. Finally, we'll consider the functional interactions that bring these systems together to form a fully operational starship. At that point we'll have a good idea of how a starship works, which will enable us to discuss in a concrete way how players can interact with these systems.

Ultimately this should demonstrate how starships are a crucial mechanism for enabling players to craft new things in ST:O in a way that's both consistent with the spirit of Star Trek and fun as a set of MMORPG features.

So let's get started, already!


THE SYSTEMS OF A STAR TREK STARSHIP

Here's my current list of major shipboard systems in the modern Trek era:

COMMAND


ENGINEERING / OPS / TACTICAL


SCIENCE


The first thing to observe about this list is that I've divided up shipboard activities into the standard three branches: Command, Engineering/Operations/Tactical, and Science. These correspond to the modern era uniform colors: Command and Helm in red, Engineering, Ops and Tactical in gold, and Science and Medical in blue or teal. (I use the term "Tactical" rather than "Security" since Tactical seems to encompass Security, Fire Control, and Communications actions in modern era Trek shows.)

I think this list fits the accepted conventions for Trek organization in the modern era (that is, from A.D. 2351 through at least 2405 according to the excellent "Spike's Star Trek Page" of uniforms at http://www.st-spike.org/pages/uniforms/uniforms.htm). But there are a number of reasonable questions that could be raised.

The first concerns the inclusion of Medical as a subsystem of Science. After all, the medical staff from ST: TNG onward wore teal- or green-colored uniforms rather than blue. For that matter, they probably have their own department within SFHQ (I expect someone can tell us that for sure). But for purposes of simplicity and consistency within ST:O as a game, it seemed to make sense to include Medical as one of the major departments within the Science branch despite their wearing the teal/green uniforms rather than the standard blue of Science. Does anyone feel strongly otherwise?

Speaking of Medical, where's the Ship's Counselor? I went back and forth on this one for a while, but ultimately concluded that while it might be an appropriate role on a ship's Table of Organization, there's no "ship system" that is operated by a Counselor. (Having an office doesn't count.) Since ship systems are what I'm trying to represent here, I decided that Ship's Counselor didn't need to be shown. But I'm open to alternative viewpoints on this one, too.

Another issue I had to wrestle with is the relative paucity of Science systems. When does a duty posting include enough scientific activity to need a Science Officer? In reviewing the various Trekanalia, I found that there's very little consistency on when a posting might or might not include a Science Officer to handle a large science department. The original NX-01 Enterprise included a Science Officer. So did the Constitution-class Enterprises, as did Deep Space Nine. But neither the Galaxy- nor Sovereign-class Enterprises had a dedicated Science Officer (rather surprising for the NCC 1701-D), nor did Voyager. In the latter cases, science seems to have been one of the (many) responsibilities of the Ops officer. (There's also a story that Gene Roddenberry didn't like the way Brent Spiner looked as Data in Science blue. Putting Data in the gold uniform wound up creating the concept of the Operations department.) To try to reflect this, I've assigned the systems related to applied sciences to Ops, and the basic sciences that remained (including Medical) I assigned to the Science branch. That meant Ops got Astrometrics / Stellar Cartography. I think that makes sense, but moving it to Science (under Physics?) might be worthwhile if there's a good case to be made for it.

Yet another reasonable question might be why Ops and Engineering (and Tactical) are divvied up the way they are. With a few exceptions (primarily Shuttle Ops and Cargo Ops), all these systems are maintained by Engineering but used by Ops or Tactical... so who "owns" them? Given the practical need to balance these departments so that no one wound up with too many responsibilities, I chose to organize their systems on the basis of whether an individual system was primarily related to information collection or operational processes -- either of those went to Ops, everything else went to Engineering. The exception was Communications, which somehow wound up being a duty of the Tactical officer. So obviously this distribution of the subsystems is somewhat arbitrary, but I think it's a pretty close approximation of what the Ops officers on the various TV shows did. It also seems to produce a reasonably balanced grouping of systems within each department, which is important for gameplay. Still, if someone wants to quibble, there's room to do so.

A final item worth pointing out is that not all starships will implement all these systems. The bigger ships will have most of them, but smaller ships won't. For instance, an in-system tug might have multiple tractor beam emitters but no torpedo launchers or warp drive. And even most of the bigger starships won't require a "space boss" to manage fighter operations because only a few ships are carriers. (I'm assuming carriers can exist in ST:O even though they never got much use in any of the TV shows or movies... and why not, I wonder?) So the fact that some ship system is on this list doesn't mean it's installed on a particular ship. I'm just listing the possibilities.

OK, then -- taking into account all these exceptions and questions, how do these systems look to you? I didn't go into great detail -- for example, I didn't list "densitometer" as a type of passive short-range Sensor, or "dilithium articulation frame" as part of the Warp system -- because I was trying to list operational systems, not specific devices. With that distinction in mind, are there any systems I failed to list that ought to be included? Are there things I listed that shouldn't be there? And what about the organization of the systems I did list -- in your opinion, are they shown where they should be, or is there a more appropriate way to group them?


THE ORGANIZATIONAL STRUCTURE OF A STARSHIP'S KEY SYSTEMS

Assuming this list is reasonably close to the kinds of things that players would like to be able to do on a Trek starship, let's now move up a level and look at how these systems are organized in terms of shipboard personnel:


The Command branch includes Command functions plus Helm and Navigation systems. Personnel assigned to Command and Helm departments wear red uniforms. Note that serving at the Helm of a starship is usually considered an important milestone in a career path eventually leading to command.

Engineering, Operations and Tactical departments share numerous systems -- Engineering maintains them, while Ops and Tactical use them. These systems include the important support systems of a starship: Power generation, Computer services, Sensors, Tactical (offensive/security) and Defensive systems, Propulsion, and several valuable subsystems which I've aggregated as Auxiliary systems. Personnel assigned to Engineering, Ops, and Tactical all wear gold uniforms to reflect their close working relationship.

Under Sciences are Medical, Life Sciences and Physics. While ships of any size may have a Medical department (and some ships, such as the future Hope-class ships as seen in ST: TNG "All Good Things", may have large Medical contingents), it is primarily the ships designed for long-range exploration that will also have Physics and Life Sciences departments. Physics and Life Sciences departments will report to the Science Officer if one is posted; otherwise they will be under the direction of the primary Operations officer.

Each of the three branches is represented at Starfleet Headquarters by appropriate members of the admiralty, who are responsible for setting policy and making high-level personnel assignments for each branch under the direction of SFHQ leadership.

This organization of systems seems OK. Even so, I'd like to suggest a change to it for ST:O. If I were designing a game set, oh, I don't know, 20 or so years after the events of ST: Nemesis, I think I might want to make a few minor alterations to Starfleet's branch organization. Specifically, I'd move Tactical to the Command branch and put those personnel in ST:O's spiffy new red uniforms. Not only would this better reflect the life-or-death decision-making by Tactical officers that is typical of Command personnel, from a gameplay standpoint it would shift some of the systems from the overloaded gold-branch to the red-branch, which is pretty empty with just Command and Helm systems.

For now, though, let's assume the organization as described above is retained for ST:O. With these organizational assignments in mind, let's next consider the functional structure of a ship's key systems.


THE FUNCTIONAL STRUCTURE OF A STARSHIP'S KEY SYSTEMS

This next diagram offers one possible interpretation of how the different systems of a large starship could interact functionally:


Obviously this diagram is a little busy, but that does serve to make the point of how deeply interconnected all of the many systems of a starship are with each other. There are a lot of things to do on a working starship!

The key resources that need to be communicated are control, power and information. Command receives information from the officers in charge of the ship's key systems and gives control commands to these officers. Power must be supplied to each of a ship's systems as requested (under the watchful eye of the Ops officer). And the computer not only provides control to certain systems (such as Power), its primary function is to provide information to any systems that ask for it through a control request. Finally, some systems (such as Sensors and Auxiliary, or Medical and Life Sciences) share information directly with each other.

This complexity is not arbitrary. The reason why starships are able to function so effectively in the hostile space between the stars is because their systems are so well integrated -- the systems that need to talk to each other are connected so that they can do so. And because there are so many connections, there is redundancy of control. If a system is damaged, it is often possible to route control or power or information around the problem. (We'll examine this in more detail in a moment.)

You'll also notice that I've grouped certain systems into "elements." For example, the Helm element contains the Helm system (comprised of Conn and Navigation) and the Propulsion system; the Tactical element includes Tactical and Defense systems; and so on. (For various reasons, the Command system is its own element.) This additional level of organization helps to show the interplay among high-level systems during the actual operation of a starship -- some connections are closer than others.

Another somewhat subtler aspect of the functionality diagram that bears comment is that while the Command element normally controls the other elements, in a pinch those elements can operate autonomously. In other words, with Helm being its own element, the duty helmsman has the capability to take action without control from the Command element if warranted by circumstances. And the same applies to Ops, Engineering, Tactical and Science -- in a pinch, each of these elements might be called on to save the day, and each is capable of doing so. There might be an inquiry afterwards, but the capability is there by design for those occasions when it's needed. So although there are obviously a lot of connections between systems, those systems are also grouped in ways that enable ship elements to function when cut off from other elements.

A last point on this diagram is in some ways the reverse of the previous point (but they're not mutually exclusive). Although elements are to some degree independent of each other, there are also many connections between elements. Not only does this support the concept of rerouting power and information, it also enables the related concept of allowing control of systems by alternate elements. For example, a severe ion storm might cut off some parts of a ship from other parts -- if the Helm system were destroyed and its duty officer lost, the Tactical officer might be called on to maneuver the ship to safety. Having multiple connections to systems would allow the Tactical officer to command the ship's computer to route power to the propulsion system, as shown in the functional diagram. It might not be efficient, but it might be just enough.


BUT WHY SO COMPLICATED?

After all these points, it's fair to ask: would starships in ST:O really need to be this complicated? I think so. In the first place, this level of complexity in a starship's form and function is a critical aspect of many Trek storylines. People and their relationships are always the most important thing, but the technology -- in particular, the operation of a starship -- helps to highlight those stories. If that's not a core component of ST:O, it just won't feel like Star Trek.

Dramatic effect comes into play here as well. Probably the two most common words regarding ship systems in all of the Trek shows are "reroute" and "divert." It seems like captains are always directing their Ops officer or Chief Engineer to reroute power around damaged systems or divert all available power to a key surviving system. It would be very strange, I think, if a game that allowed players to be responsible for various ship systems didn't include this capability, or the similar requirement that nearly all ship's systems require an active link to the ship's computer. (How many times have we heard exclamations like "The starboard power coupling's gone!" or "I've lost helm control!" when a critical system loses its access to power or the main computer?)

Implementing starships in ST:O according to the functional structure diagram above would support this dramatic redirection of ship resources. Players with the appropriate authority, like their fictional counterparts, could help save the ship and its mission by diverting power from life support to the shields at a critical moment, or by restoring helm control by rerouting it to a workstation in Engineering that still has computer access, and so on. These kinds of actions would be creative tasks that would allow ship's personnel to shine by devising novel solutions to tough problems... just like they do on Star Trek.

An important second reason for giving starships some serious depth is that many of those who'll be drawn to a game like ST:O will, I think, be the kind of people who find complex systems more interesting (read: more fun) than trivially simple objects. Certainly there's room for simple objects in any MMORPG. But ST:O, if it's really going to honor the Star Trek ethos of exploration, is exactly the right game to offer more exploratory depth for the people who appreciate that kind of play.


HOW DESIGNING STARSHIPS AS SYSTEMS ENABLES CRAFTING

Which brings us -- finally! -- to "crafting."

Here's the summary: many of the tasks performed on a starship are routine. I call these "control tasks" to indicate that they're about normal control of ship systems. These are things like maintenance and simple repair tasks, which don't call for anything particularly interesting from players. Simulating that sort of thing in a MMORPG may be going too far.

But some tasks can't be accomplished by routine actions. I call these "creative tasks" to highlight their dependence on creative thinking and novel solutions to unexpected and difficult problems. This is what ST:O's design should be focused on offering to players, because this is what makes characters in the Star Trek universe special.

Creative tasks break down into two kinds: new ways of using existing tools (where "tools" means hardware devices and software programs), and the development of new tools. In turn, the development of new tools comes in two flavors: writing short programs to alter an existing device's default behavior, and creating new devices.

Here's how this looks in outline form:


The creation of new programs and devices is what I mean by "crafting" in the world of Star Trek. Using existing tools in new ways to solve a problem is definitely a creative task, and I hope ST:O is designed to reward that kind of gameplay. But it's also important for ST:O to reward the fabrication of new things, which is a little closer to the notion of crafting in current MMORPGs (and so may be more familiar to current online gamers).

To provide a better idea of these categorizations, here are some examples of each type of creative task from the various Star Trek TV shows and movies.

New uses of existing tools:


New programs:


New devices:


The point to listing all these examples is to demonstrate that the creative use of technology to solve problems is a fundamental part of Star Trek. Exploration means encountering new situations that don't respond to old ways of doing things. Being able to adapt to the unexpected is thus a hallmark of the explorer.

What's important to see here is that this creative adaptability -- building new tools and using them in new ways -- is both interesting to do in its own right and exciting when told as a story. Solving a problem that only occurred because we made the deliberate choice to expand the horizons of our knowledge makes for a dramatic story. All the best Star Trek episodes and movies showed that creative problem-solving is fun and dramatic.

Because Star Trek Online will be interactive, it needs both of those things even more than the TV shows and movies. Implementing starships that are detailed enough to give players many tools for solving challenging problems can insure that ST:O players enjoy all the fun and drama of Star Trek, and then some.


STAR TREK CRAFTING IN DETAIL

Now let's look a little more closely at the twin crafting concepts of making new devices and writing new programs that change the functionality of devices.

New devices are a Trek staple. One of the side effects of having stories based on advanced technology is that if you need a "McGuffin" for a story, you can simply declare that it exists. Name it with some bit of plausible pseudo-scientific gibberish and you're good to go.

The result of this in Trek is that new devices (new to both the characters and to viewers/players) show up all the time. It's part of Star Trek; there's always some new gizmo that's useful or dangerous (or both) to contend with, or a need to make a new device to solve an urgent problem. So it's only natural that new devices play a meaningful role in a Star Trek MMORPG as well.

There are two ways to accomplish this. One is for ST:O developers to make like Star Trek writers and pre-invent all the new devices that players will ever encounter (perhaps through away missions). That would keep everything canon, but it could chew up a lot of development time. Even worse, no matter how many devices are written by the developers, players will discover virtually all of them in a few months. Once the pregenerated content has been burned through, then what?

The other approach is to let players create their own new devices. This would also require significant development time to do it right, but it has the advantage of being dynamic content that changes for every player and thus never gets stale. It would also do a much better job of letting ST:O players feel like characters in the Star Trek universe because it lets players do what they've seen Star Trek characters frequently doing.

The key to letting players make new devices is for the developers to create basic components, to build the standard set of supplied devices (including starships) out of these components, and to give players a way to take devices apart and put them back together again in new ways and with new components for modified or new functionality.

Suppose you've just finished trading with a representative of the Kylari homeworld, and one of the things you picked up is a subspace phase modulator assembly. Your existing phase modulator is pretty good, but it looks like your subspace scans might be a little more accurate if you could figure out how to integrate this new device into your sensor system. At this point in a TV episode, your ship would get a distress call from somewhere in subspace -- wouldn't it be cool if you could save the day by analyzing the inputs and outputs of the old and new devices and work out how to replace the old one with the new one so that you can find the vessel lost in a subspace inversion?

Or maybe you pick up an improved phase capacitor lattice on an away mission. If devices are built from components, you might be able to field-strip your phaser to use the new capacitor lattice for (say) improved collimation (i.e., more thermal damage but at a significantly higher power drain). By being able to break down devices into components and using different components of the appropriate type to rebuild devices, players could use their ingenuity to solve technological problems just like characters in Star Trek.

Of course this is a massively multiplayer game. To keep this device-making ability from getting out of hand so that Federation players don't rapidly wind up with hand-held plasma torpedo launchers, several kinds of constraints could be considered:


These rules could definitely be tweaked; I'm just listing some ideas to acknowledge that there'd need to be reasonable limits on creating new devices. Not so much that this important aspect of Star Trek loses its impact, but just enough so that Federation gear still feels like Federation gear after the game has been going for a few years.

The other concept needed to support crafting in ST:O is programming. At least as often as characters invent new devices -- and probably more so -- they also change how devices behave by modifying the programming that binds devices together into complex systems.

Sometimes you can get what you need by issuing a normal command to a device, such as "EPS manifold R-27, change your output route from EPS junction 34-A to 34-B" or "deflector emitter, apply a frequency modulation of 72.831 megacycles per second to the next tachyon pulse" and so on. That's the kind of thing I call "new processes."

But there are also times when changing a particular device's output isn't enough -- you need to change how an entire system behaves on an ongoing basis. That's when the programs controlling the standard behaviors of systems need to be altered, either with modifications or with completely new programs.

As the examples earlier showed, this kind of system-modification goes on all the time in Star Trek shows and movies. Being able to tweak how a system performs over time is a common task. It's not a "control task" because it's something out of the ordinary, but it's common as a plot feature in Star Trek fiction. It's also an interesting gameplay feature. Consequently, ST:O would benefit from including it as well.

As with devices, the most satisfactory way to let players program systems is for the developers to build systems of devices with default programming, and then allow players to change those system-control programs. In effect, ST:O would have its own standard computer language for controlling and connecting devices. Complex systems (such as warp drives and sensor arrays) would be built by Perpetual out of devices and programs that reside on the local computers that connect those devices. When a player finds that the default system isn't sufficient, he or she could rewrite its programming to improve it, making it more efficient or giving it new capabilities.

Naturally this feature needs to be carefully considered for how it would work in a massively multiplayer online game. One of the most common objections to letting players develop their own programs is that some players will choose to use this power to annoy other players. It's a fair objection, but I think there are also a couple of good responses that can be made to it.

First, a familiar part of shipboard Star Trek is the concept of the "authorization code" (or, in the case of command personnel, their command codes). Although we tend only to see these used in dramatic situations, it's been supposed that entering these codes is actually a standard action. When you start to use a terminal or workstation, the first thing you do is enter your auth code. This serves several purposes: one, it restricts your actions to only those which you are authorized to perform; two, it tags everything you do with your identity (and a timestamp); three, it can be used to lock hostiles out of sensitive systems; and four, it accesses all of the LCARS keypad configurations that you've predefined for performing specific activities. (More on that in a moment.)

The first three of these purposes serve the need for security. By restricting actions to users with appropriate privilege levels, and by logging permitted actions, the use of auth codes would limit griefing. (The third use of auth codes, to lock systems, might be griefed, however.) Still, players serving aboard a starship who use their power to compromise ship systems would likely be caught and shown to the nearest airlock. Even better, restricting systems to authorized (trusted) players only would make it harder for the typical griefer to do real damage. In any event, "programs" to operate ship systems are not at all the same thing as the macro and script commands used to automate player actions in some current MMORPGs -- you might be able to automate a ship, but characters couldn't turn themselves into AFK bots. (And even automating a starship is not without risk -- remember what happened when Dr. Daystrom plugged M5 into the Enterprise? Faulty programming of a starship's systems should have consequences.)

The second response to the "players will abuse the power to write programs" objection is to point out that, in many of the Trek shows, someone does abuse this power! Whether it's Spock faking library tapes (ST: TOS, "The Menagerie") or Ceska hiding a booby trap in Tuvok's mutiny simulation (ST: VOY, "Worst Case Scenario"), it seems like someone is always finding a way to circumvent the security features of starship computers. If ships in ST:O can be boarded by hostiles, or NPCs serving aboard player ships can ever turn out to be saboteurs, then allowing a certain amount of leeway in spoofing a ship's computer might actually prove to be a game feature that players would enjoy because it would let them live out the plot of a typical Star Trek episode.

Perhaps a more powerful objection to letting players write system-control programs is "people want to play a Star Trek game, not program virtual computers." That's absolutely true... for some people. Those who prefer more "physical" or social activities in the game world will no doubt be able to satisfy those interests, but I'm confident that there are other gamers (including people who like Star Trek) who would find equal enjoyment in the technological problem-solving in a Star Trek setting that ST:O could provide. For these gamers, the chance to save the day by reprogramming the transporter system to accept an unscannable material (for example) would be an incredibly satisfying experience.

Taken together, I believe that offering these forms of crafting -- the ability to create new devices and new programs to control a starship's systems -- is such an iconic part of Star Trek that it is crucial to ST:O's success. Allowing players to solve problems through the manipulation of advanced technology is a great way to help them feel like a part of the Star Trek universe.

Crafting as part of exploration is so fundamental to Star Trek that implementing it in ST:O will contribute significantly to getting the most value out of the Star Trek license.


BUT WHAT DO SYSTEMS OPERATE ON?

There's one other point that's related to "crafting" creative solutions to difficult problems, but which isn't directly related to ship's systems. That being the case, I won't go into detail about it here, but it's worth mentioning. And that is the amazing variety of fields and particles and waves and energies that make up the Star Trek universe. (As someone has put it, "Star Trek is one of the greatest sources of technobabble ever." There's a reason why the neologism "treknobabble" was coined....)

From tachyons to polarons to chronotons to vertirons and beyond, Trek is overflowing with things that can be sensed and/or emitted. To truly allow ST:O to feel like Trek, players will need to be able to direct the various systems of their ships to detect these things and (when appropriate) to emit them in multiple modes. Space needs to be full of all these forms of matter and energy in order to give players materials for their ship's systems to operate on -- they are a prime source of challenges to be addressed in creative ways.

This is a topic ripe for in-depth discussion....


SYSTEMS OPERATION AND THE LCARS INTERFACE

To close this subject of working with devices and programs and systems in a Star Trek game, a note about LCARS interfaces. While I expect some differences between how they work in film Trek and in a MMORPG (both for the sake of novelty and because a game will surely require some compromises), I'd be very surprised if the LCARS visual interface wasn't used somewhere in Star Trek Online. Unless ST:O is going to support full voice recognition, we might as well get some additional use out of all those Okudagrams!

On the assumption that some version of the LCARS interface will be the means by which players operate ship systems, the details of this interface are worth a few observations as they relate to performing control tasks and creative tasks.

Overall, I would suggest that some thought be given making certain functions part of a common user interface. In particular, I think every display panel should include at least the following components:


These aren't meant to constitute a complete list of common user components. I expect there'll be more; this is just a first crack at a definition -- feel free to suggest others! But these capabilities in particular would serve at least three useful purposes.

First, although every standard ship function should have a default LCARS layout, allowing players to create their own screen layout for any activity will allow them to perform their duties more efficiently. For example, Player A might want to configure a helm control layout in which impulse and warp controls are on the main screen and thruster controls are on a pop-up screen. But Player B might prefer to lay out her helm control screen so that all three modes are on the same page, with thruster controls on the left side because she's left-handed. And Player C might want to have several helm control layouts suited for different tactical situations. Allowing players to configure LCARS screens will go a long way toward personalizing the game for each player, increasing the sense of immersion in the Trek universe.

Another aspect of allowing players to configure screens is to support players with multiple shipboard responsibilities. Once they've configured layouts for each of their tasks, a player will be able to switch between functions by selecting the appropriate control. For example, an Ops officer could be monitoring sensor channels when a telltale lights up indicating that a shuttle launch is in progress. By pressing the Function control, then selecting the config for the Shuttle Ops function, the LCARS display for shuttle operations can be quickly displayed, allowing the Ops officer to inform the captain that yet another unscheduled shuttle launch has occurred. (Those seem to happen pretty regularly in the Star Trek universe, don't they?)

Lastly, allowing displays to be defined for individual users will let players bring up their preferred screens on whatever workstation they happen to be using. This will be especially helpful for those players whose duties take them all over the ship, as opposed to players whose functions have dedicated Bridge or Engineering stations.

In summary, this level of flexibility in control panel configurations would enable players to respond quickly to challenging situations with creative solutions. As the primary interface to modifying or using ship systems (in a game that probably won't include computer voice recognition), it's important to have a control system that players can tailor to their preferred styles of thinking and acting.


STARSHIP SYSTEMS AS A VEHICLE FOR ETHICAL EXPLORATION

There's a final reason I'd like to mention for designing ST:O so that players can manipulate the advanced technology aboard powerful starships. It's that giving a character power helps tell good stories.

Technology in Star Trek has never been just about the gadgets -- it's always about when to use those gadgets and when not to. In other words, the high tech of Star Trek exists to raise questions (in dramatic form) about the right uses of power. This is the same premise that drives all good science fiction -- when advanced technology lets you do nearly anything you like, under what conditions should you refrain from using your power? Should human limits still apply when machines can augment your senses and skills and even intelligence? (Star Trek's Borg ask this question in a startlingly direct way.)

Star Trek has always held that with power comes responsibility. When you have power over life and death, over time and space, and you choose to go exploring, your power over the people you encounter will generate ethical dilemmas. When is it right to use power, and when is restraint the right decision? This conflict drives many of Star Trek's best stories:


But not everyone chooses to use their technological and intellectual capabilities for selfless reasons. Some of the greatest villains in Star Trek have been those who chose to use their power without regard to the consequences to others:


In particular, the Prime Directive has been the source of a vast amount of storytelling in Star Trek precisely because it places self-imposed limits on the use of power. Stories testing the boundaries of the Prime Directive have been as valuable to Star Trek as stories testing the Three Laws of Robotics were to Isaac Asimov, and for the same reason: the intersection where hard-and-fast rules governing conduct meet the real world is where there's the most potential for conflict, and conflict makes for good storytelling.

How firmly do you hold to your principles that tell you to refrain from using power? What about when using that power could save you from destruction or relieve the suffering of innocents? When is it OK to bend your principles? How far can you bend them before they break? That's the conflict at the heart of great drama. It's been the source of many of the strongest stories in the Star Trek universe.

It can and should be the source of strong gameplay in Star Trek Online as well.


CONCLUSION

Which brings me at long last to my conclusion: implementing detailed and powerful starships for players to use in Star Trek Online is such an effective mechanism for bringing the spirit of the Star Trek license to life that it should be a key design feature, not dismissed as a "starship simulator."

Detailed and powerful player starships satisfy the two requirements for good storytelling in the Trek universe. The detail enables crafting that would offer ST:O players what legendary game designer Sid Meier has called "interesting decisions." And the power ensures that those interesting decisions carry ethical weight. Without the detail or power, a core aspect of Star Trek is lost -- either it's not possible to generate creative technological solutions to problems, or those solutions are mere grinding without meaning. In either case, it won't feel like Star Trek, and it won't be a fun online computer game.

Yes, Star Trek Online must do more than just tell a good story -- it needs rules of play to make it a good game. Detailed starships and other devices enable gameplay by offering a rich environment for crafting and tool-based problem solving. But why stop there when it's possible to make a great game by ensuring that ST:O's gameplay is driven by the deeper humanistic ideals of Star Trek?

ST:O should be more than "just a game," just as Star Trek was more than "just a TV show." And it can be, if the player operation of detailed and powerful starships is a core design element.